Personal computer systems are well known in the art. They have attained widespread use for providing computer power to many segments of today's modem society. Personal computers (PCs) may be defined as a desktop, floor standing, or portable microcomputer that includes a system unit having a central processing unit (CPU) and associated volatile and non-volatile memory, including random access memory (RAM) and basic input/output system read only memory (BIOS ROM), a system monitor, a keyboard, one or more flexible diskette drives, a CD-ROM drive, a fixed disk storage drive (also known as a “hard drive” or “hard disk drive”), a pointing device such as a mouse, and an optional network interface adapter. One of the distinguishing characteristics of these systems is the use of a motherboard or system planar to electrically connect these components together. Examples of such personal computer systems are International Business Machine Corporation's (IBM's®) PC 300, ThinkCentre, ThinkPad, Aptiva, and IntelliStation series of personal computers.
Networks such as the Internet and corporate intranets provide a mechanism for users to transfer data among computers for information sharing, workplace collaboration, data collection, etc. Users gain access to networks such as the Internet by accessing a web server via personal Internet service providers (ISP's), broadband network connections, or high speed network connections through office systems. Typically, a user will view Internet or intranet content using a graphic browser application such as Microsoft Corporation's Internet Explorer, Netscape Communication Corporation's Navigator, Mozilla, Apple Corporation's Safari, etc. Browsers, at their most basic level of operation, permit users to connect to a given network site, download informational content from that site, and display that information to the user. To view additional information, the user designates a new network address (such as by selecting a link) whose contents then replace the previously displayed information on the user's computer display.
For traditional web applications, a single session is established for a user each time the user logs into the web server. Unlike desktop computers, a web server often handles many users simultaneously. A session management mechanism at the web server allows maintaining most of each user's state information (i.e., session information) at the web server while only passing necessary information (for instance, the session identifier) back to the user via cookies, Uniform Resource Locator (URL) rewriting, a Hypertext Markup Language (HTML) hidden field, etc.
As the amount of information available to users continues to dramatically increase, portals have become more and more popular for aggregating and displaying information to users. Portals are an entry point or gateway for access to other web sites and information and provide a single point of access to a wide variety of content, data, knowledge, and services throughout an enterprise or network. As such, they have become increasingly popular with users as a starting point (often designated as their “home page”, the first page displayed when they start their browser) for their use of a network. Publicly accessible Internet portals include Yahoo! Corporation's My Yahoo!, Microsoft Corporation's MSN, Google Corporation's Google News, etc. More specialized portals also exist, such as news sites such as Cable News Network LP, LLLP (“CNN”) CNN Interactive, MSNBC, sports sites such as ESPN Inc.'s ESPN.com, etc. Private portals, including Time Warner Inc.'s America On-Line (AOL) service, are also popular. Many large companies also provide portals on their corporate intranet for use by all of their employees or groups of employees.
Portals allow a user to view content or links to multiple other sites (at different network addresses) simultaneously on one display, rather than forcing users to only view content from one site at a time. An Internet portal could, for example, simultaneously provide users with content from a news service, weather service, sports score service, etc., with each service potentially being provided by a different site. If the user desired more information from any of those services, the user could select the link to that service and the portal would facilitate the connection between the user and the other site. A portal server that provides a portal typically has a session management mechanism to maintain the session information for each of the multiple transactions (i.e., access to multiple sites) with the user. In a traditional web server, each user only needs to establish one session with the server per login, whereas each user may need to establish several sessions to request the different services provided through a portal system, including one session for the primary portal server and an additional session for each backend application.
Each service or other application provided by a different site than the portal server's network site is often called a backend application. A session with each backend application accessed by the user may be required in addition to the session established with the portal for the same user. For instance, if a backend application requires a separate login, then a user session may be created by the backend application to trace user states of multiple transactions. Each backend application typically has its own session management mechanism, resulting in different types of session data passed to the user and different ways that the data is passed (e.g., cookies, URL rewriting, etc.). Portals may pass this session information, along with the content, generated by the backend applications to the user and forward the session information from the user to the backend applications. Because each backend application uses its own session management mechanism, session data may be lost because of session identifier collision when the same user identifier (e.g., cookie name) is used in different backend applications to hold session identifiers as a “collision” will occur from the repetitive use of the same identifier. This problem is exacerbated with Sun Microsystems, Inc.'s Java applications as a default session management cookie name (e.g., ‘JSESSIONID’ required by the Servlet specifications 2.3 and 2.4) may be required for all cookie-based session identifiers. When such default names are used by more than one application, the cookie names are not unique and a collision will occur.
Modifying the session management mechanisms of the backend applications so that collisions do not occur is one solution to the problem of collisions. This solution, however, would require a significant amount of time and resources to accomplish, as each backend application is often written by a different provider and changes to universal standards, such as Java, would be required. As portal owners continue to provide new, additional and varied content, the problem of ensuring that each backend application uses different names becomes more and more difficult.
Using a unified token as a session identifier, such as in Microsoft Corporation's Single Sign-On user authentication mechanism, has also been considered as a solution to the collision problem. In this solution, a portal server issues a token to the user in a cookie, which is stored in the user's browser memory and passed to all backend applications during the user's transactions. This solution is flawed, however, in a number of respects. First, all participating applications must agree on the format and name of the token, which may prove difficult when applications are created by different providers. Moreover, all participating applications must be in the same domain name server (DNS) domain, as cookies are issued with a domain name and will not work with others. A token mechanism will therefore require significant changes to existing applications and will be limited in its applicability, making it undesirable as a solution.
There is, therefore, a need for an easy and effective mechanism for managing multiple sessions on a portal, particularly for managing sessions from different applications. There is an even greater need for such a system when the applications are located in different domains.